Hand-held electronic devices, such as Personal Digital Assistants (PDAs), Personal Video Players (PVPs) and other types of media players can be held in a portrait orientation or in a landscape orientation.
In the portrait orientation, a long dimension of a display screen of the electronic device is vertical, whereas in the landscape orientation, the long dimension is horizontal. In order to generate images on the display screen, image data in the form of pixels is read by a display controller from an area of memory (frame buffer) and painted on the display screen. The layout of the pixels (portrait or landscape) in the frame buffer is determined by the display controller hardware, with many current devices using portrait mode displays. If the electronic device is to be used in an orientation that is not the same as the display orientation it will be necessary to rotate the pixels prior to storage in the frame buffer for display. For example, if the image data is stored in a landscape memory layout, and the electronic device uses a portrait mode display, then it is necessary to rotate the image data 90 degrees before displaying in order to ensure the correct orientation of the displayed image.
The rotation of the image data as described above may be performed in hardware or in software.
However, in some types of hardware, such as the Intel XScale processor, there may be no support for hardware image rotation. In this case it is necessary to add an additional external display controller that supports rotation. Adding an external display controller increases overall system cost, thus leading to a competitive disadvantage.
Alternatively, the image rotation may be implemented in software. Traditional software solutions to implement image rotation follows the order of processing shown in FIG. 1 of the drawings, an example using compressed video as the image source. As can be seen, there is first a decode stage 100 where source data (typically YUV data, i.e., data from the YUV color space in which a Y channel carries luminance information and a U and V channel carry chrominance information) is produced from compressed images. Thereafter, at 102 a color conversion transformation is applied to the decoded data to convert the data to the RGB (red/green/blue) color space. Finally at 104, the image data is rotated before being sent to a display screen. Having a separate color conversion step and rotation steps can significantly reduce the overall frame decode rate since the entire image data will have to be processed, including memory loading and storing, twice—once to do the color conversion and once to do the rotation. This slows the rate at which images can be displayed, which especially in the case of video images degrades a user's overall experience.